December 95 - Guidelines for Effective Alerts
Guidelines for Effective Alerts
Paige K. Parsons
This article expands on the Macintosh Human Interface Guidelines for making
attractive, helpful alerts (and dialogs) with a standard appearance and behavior.
Standardization is important, because the more familiar an alert looks to users, the
more easily they can concentrate on the message. Using the Finder as a source of good
alerts, we provide examples of different alert types and discuss how to make alerts
user-friendly.
Alerts are an in-your-face way of getting the user's attention. It's hard for a user to
ignore alerts because they block all other input to the application until the user
dismisses them. These little windows are powerful stuff. When used correctly, alerts
are a helpful way to inform the user of a serious condition that requires immediate
attention. When used incorrectly or capriciously, alerts are annoying and disruptive;
since they must constantly be swatted out of the way, their content is often ignored.
This article discusses when to use alerts, describes the different types of alerts, and
gives tips for designing alert boxes. It elaborates and expands on alert guidelines in the
Macintosh Human Interface Guidelines. At the end of the article, you're encouraged to
try your hand at evaluating some real-life alerts.
Though not implemented as such in the system, alert boxes are essentially a type of
modal dialog box. This article focuses on alerts, but the guidelines can be applied to
other dialog boxes as well. We specifically cover status dialogs here because there are
guidelines that are unique to that type of dialog.
For information on implementing alerts and dialogs in your application,
seeInside Macintosh: Macintosh Toolbox Essentials.*
ALERTS IN GENERAL
Alerts provide information about error conditions and warn users about potentially
hazardous situations. They should be used only when the user's participation is
essential; in all other cases, try using another mechanism to get your point across. For
example, consider an error or output log if the messages are something that the user
may want to save.
recommendation in this article: that alerts be movable and application modal. The
current interface guidelines and system software don't allow alerts to be movable, but
this may change in future versions of the Mac OS. Until then, you can implement your
alerts as movable modal dialogs.
Making alerts movable is helpful in case an alert is covering information on the screen
that the user would like to see before responding to the alert. Another advantage to
movable alerts is that they have a title, which gives the user a context for the error.
Application modal means the alert is modal in the current application only: the user
can't interact with this application while the alert is on the screen, but can switch to
another application. This is especially useful when the user needs to get information
from another application in order to respond to the alert. (System modal, on the other
hand, means the user can't interact with the system at all except within the alert box.)
TYPES OF ALERTS
Alerts come in three varieties, each of which is geared to a different situation. This
section provides a few examples of each type, and also takes a look at status dialogs.
NOW HEAR THIS: NOTE ALERTS
no drastic effects and requires no further action. For example, if a user selects a word
and executes a spell check, an alert saying that the word is spelled correctly would be a
note alert. Rather than provide a smorgasbord of options, a note alert contains a single
button to dismiss the alert.
Don't use an alert to signify completion of a task; use alerts only for situations that
require the user to acknowledge what has occurred. For example, the following note
alerts are inappropriate and get in the user's way:
• The Trash has finished emptying.
• The 3,432 files you selected have been copied.
WATCH OUT! CAUTION ALERTS
Caution alerts warn users of potentially dangerous or unexpected situations. You
should use them, for example, to be sure the user wants to proceed with a task that
might have undesirable results. In this case the alert normally contains only two
buttons -- one that cancels the operation and one that confirms it. Here are two
caution alert messages:
• An item named "READ ME" already exists in this location. Do you want to
replace it with the one you're moving?
• The Trash contains 1 item. It uses 102K of disk space. Are you sure you
want to permanently remove it?
Don't use alerts to confirm operations that would cause only a minor inconvenience if
performed by mistake. Here are two examples of unnecessary caution alerts:
• Do you really want to eject the disk "Installer"?
• Do you really want to duplicate the selected item?
Caution alerts are also used when an unexpected situation occurs and the user needs to
decide what to do next. The following examples contain only two buttons, for canceling
or confirming the operation, but such an alert may present several choices if
appropriate.
• The document "Calendar" is locked, so you will not be able to save any
changes. Do you want to open it anyway?
• The item "Calendar" could not be deleted, because it contains items that
are in use. Do you want to continue?
Before deciding to use this type of alert, double-check to see if it's really needed;
superfluous alerts are a bad idea because users will get in the habit of dismissing
alerts and possibly let an important one go by. It's better to have a user make choices
with commands instead of alerts. For example, the Finder has separate Shut Down and
Restart commands (in its Special menu) instead of having only a Shut Down command
with an alert asking "Restart after shutting down?
HOLD IT: STOP ALERTS
Use a stop alert when calling attention to a serious problem that prevents an action
from being completed. They typically have only one button, to dismiss the alert. Here
are two good examples of stop alerts:
• You cannot copy "Calendar" onto the shared disk "Zippy" because the disk
is locked.
• The alias "Calendar" could not be opened, because the original item could
not be found.
It's especially important in stop alerts to give enough detail about the problem to help
the user prevent it in the future. The following alert message doesn't convey much
useful information:
• You cannot rename the item "Zowie".
This alternative is more helpful:
• The name "Zowie" is already taken. Please use a different name.
Similarly, if the chosen name is too long, it's more helpful for the message to state the
maximum number of characters a filename can have.
EVERYTHING IS OK: STATUS DIALOGS
Status dialogs inform the user when an application is busy and the user cannot
continue working in the application until the operation finishes. In the Finder, these
operations include copying, moving, and deleting files. Status dialogs should be
displayed whenever the application is busy for more than about five seconds (unless
posting and updating the dialog would take most of that time). During this time the